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Foreword 



id , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies stage two of the Packet Data on Signalling channels service (PDS) which allows packet 
data transmission in GSM networks on dedicated channels. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 04.06: "Digital cellular telecommunication system (Phase 2+); Mobile Station - Base Station 

System (MS - BSS) interface Data Link (DL) layer specification". 

[3] GSM 04.07: "Digital cellular telecommunication system (Phase 2+); Mobile radio interface 

signalling layer 3 General aspects". 

[4] GSM 04.08: "Digital cellular telecommunication system (Phase 2+); Mobile radio interface layer 3 

specification". 

[5] GSM 05.05: "Digital cellular telecommunication system (Phase 2+); Radio transmission and 

reception" 



3 Abbreviations 

Abbreviations used in the present document are listed in GSM 01.04 [1]. 

Additionally, in the present document the following abbreviations apply: 

PDP Packet Data Protocol. Is used as a generic term to refer to standardized packet data protocols like 

X.25 or IP. 



Main concepts 



The Packet Data on Signalling channels service (PDS) is a bearer service enabling circuit oriented point to point 
transfer in GSM networks of very small data packets on radio interface signalling channels for applications using short 
dialogues with a duration in the range of a few seconds. For transmission on the air interface, the service uses protocols 
of the CM sublayer, the PDSS1 and PDSS2 protocols. 
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The provision of a mass market packet data service in GSM, where many users want to transfer very small data packets, 
leads to a significant increase of signalling traffic. This may cause load problems especially for the SCCP on the A 
interface. The PDS service offers two variants in order to allow for efficient transmission within the network: 

PDSS1: Service offered at service access points in the mobile station and MSC which uses an underlaying 

MM connection and a signalling connection on the A interface (an SCCP connection): The service 
may be offered in parallel to other CM sublayer services; MSC controlled handover is possible 
during the transmission; the MM connection related functions (subscription checks and MM 
security functions) are applicable. At radio link failure the mobile station may require re- 
establishment of the MM connection. The same subscription and charging mechanisms as for 
circuit switched services are applicable to the service. 

PDSS2: Service offered at service access points in the mobile station and a new network entity, the PDSS2- 

Support Node (PDSS2-SN), which has an interface to the BSS, the A p interface, where an MM 

connection and a signalling connection on the A interface are not required: Mobile terminated CM 
establishment may not be possible during a PDSS2 connection; more than one PDSS2 connection 
to a mobile station in parallel are not possible; with these exceptions, the service may be offered in 
parallel to other CM sublayer services. After a handover, dedicated channel assignment, or radio 
link failure the PDSS2 connection may be resumed; the MM connection related functions, 
subscription checks, and MM security functions may not be applicable (but similar functions can 
be implemented in the application). The subscription and charging mechanisms defined in GSM 
for circuit switched services may not be applicable to the service (however, the application may 
implement such mechanisms). Only mobile originated establishment of a PDSS2 connection is 
possible. 

4.1 Service characteristics of PDSS1 

The PDSS1 service access points are at the MSC/VLR and the MS. 

The MSC/VLR may be accessed to establish a PDSS 1 connection for transmission of data packets of a specific 
application, e.g. 

[* SMS, ffs, or] 

* a packet data protocol 

to a certain MS (identified by IMSI) which is supposed to be registered in the MSC area; 

the MSC may also be accessed for a data request, i.e. the request for transmission of the application on an 
established PDSS1 connection, and for release of the connection; 

at the SAP, the MSC may perform a data indication, i.e. indicate a data packet received from the MS, and 
indicate establishment/release/abortion of a PDSS1 connection; 

at the SAP, the MSC may give an indication that data transfer has to be suspended or can be resumed; 

The MS may be accessed to establish a PDSS 1 connection to the network for transmission of data packets of a 
specific application; 

the MS may also be accessed for a data request, i.e. the request for transmission of a data packet on a established 
PDSS1 connection, and for release of the connection; 

at the SAP, the MS may perform a data indication, i.e. indicate a data packet received from the MSC, and 
indicate establishment/release/abortion of a PDSS1 connection; 

at the SAP, the MS may give an indication that data transfer has to be suspended or can be resumed. 
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The service quality is that one offered by the Um layer 1, layer 2, and layer 3 sublayers RR and MM to the Um layer 3 
CM protocols, see TS GSM 05.05, TS GSM 04.06, TS GSM 04.07, and TS GSM 04.08 (transmission on the A and 
Abis interface being regarded to have ignorable impact). From these specifications, e.g., 

minimum, maximum, and mean time between PDSS1 establishment request and confirmation (dependent on 
certain system parameters and options), 

minimum, maximum, and mean time for fulfilling a data request, 

the fact that until PDSS1 connection release or abortion, packets are transferred without loss and in the right 
order 

can be derived. 

The abstract service primitives defined at the service access points and their main parameters are shown in the 
following tables 2 : 

Table 1 : Service Primitives at the PDSS1 Service Access Points 



EST REQ (Appl-id 1 ; channel type; MSCTMSI) 

EST IND (Appl-id 1 ; channel type; MSCTMSI) 
EST RSP (MSCxhannel type) 
EST CNF (channel type) 

DATA REQ (data) 
DATA IND (data) 

SUSPEND IND 
RESUME IND 

ABORT IND (abort cause) 

REL REQ (release cause) 

REL IND (release cause) 



Table 1a: Parameters of PDSS1 Service Primitives 



Appl-id := unstructured 

I [SMS, ffs] 
IX.25 
IIP 

I [ffs] 

channel type 3 := SDCCH 
I FACCH(F) 
I FACCH(H) 
I SACCH 

I no preference 4 

abort cause := service not authorized 

I Application not supported on PDSS1 

I illegal MS 

I illegal ME 

I <other reject causes of MM, see TS GSM 04.08> 

I RR connection aborted 

release cause := normal 

I service not authorized 

I Application not supported on PDSS1 

I RR connection aborted (only in REL IND) 
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NOTE 1: If the Appl-id specifies "unstructured", the service primitive may in addition specify a called party BCD 
number. In all other cases, the PDUs contained in DATA REQ/IND are expected to contain the address 
information. 

NOTE 2: The possibility of data piggy backing is not considered in these tables. 

NOTE 3: For indication of the preferred or chosen channel. 

NOTE 4: Only in EST REQ and EST RSP 

4.2 Service characteristics of PDSS2 

The S2 service access points are at the PDSS2-SN and the MS. 

at the SAP, the PDSS2-SN may be accessed for a data request, i.e. the request for transmission of the specific 
application on an established PDSS2 connection, and for release of the connection; 

at the SAP, the PDSS2-SN may perform a data indication, i.e. indicate a data packet received from the MS, and 
indicate establishment/release/abortion of a PDSS2 connection; 

at the SAP, the MS may be accessed to establish a PDSS2 connection to the network for transmission of data 
packets of a specific application, e.g. 

[* GPRS, ffs, or] 

* a packet data protocol; 

at the SAP, the MS may also be accessed for a data request, i.e. the request for transmission of a data packet on a 
established PDSS2 connection, and for release of the connection; 

at the SAP, the MS may perform a data indication, i.e. indicate a data packet received from the network, and 
indicate establishment/release/abortion of a PDSS2 connection- 

at the SAP, the MS or PDSS2-SN may give an indication that data transfer has to be suspended or can be 
resumed. 

The service quality is that one offered by the Um layer 1, layer 2, and layer 3 sublayer RR , see TS GSM 05.05, TS 
GSM 04.06, TS GSM 04.07, and TS GSM 04.08 (transmission on the Abis interface being regarded to have ignorable 
impact and transmission on the A„ interface being assumed to have ignorable impact) with the restriction that handover 

causes abortion of a PDSS2 connection. From these specifications, e.g., 

minimum, maximum, and mean time between PDSS2 establishment request and confirmation (dependent on 
certain system parameters and options), 

minimum, maximum, and mean time for fulfilling a data request, 

the fact that until PDSS2 connection release or abortion occurs, packets are transferred without loss and in the 
right order 

can be derived. 

The abstract service primitives defined at the service access points and their main parameters are shown in the 
following tables-': 
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Table 2: Service Primitives at the PDSS2 Service Access Points 



EST REQ (Appl-id^; MS identity; data volume 2 ; channel type) - only at MS side 
EST IND (Appl-id 1 ; MS identity; data volume 2 ; channel type) - only at PDSS2-SN side 
EST RSP (data volume 2 ; channel type) - only at PDSS2-SN side 
EST CNF (data volume 2 ; channel type) - only at MS side 



SUSPEND IND 
RESUME IND 

DATA REQ (data) 
DATA IND (data) 

ABORT IND (abort cause) 
REL REQ (release cause) 
REL IND (release cause) 



Table 2a: Parameters of PDSS2 Service Primitives 



Appl-id 


:= unstructured 




1 [GPRS, ffs] 




IX.25 




IIP 


channel type^ 


:= SDCCH 




1 FACCH(F) 




1 FACCH(H) 




1 SACCH 




1 no preference^ 


abort cause 


:= service not authorized 




1 Application not supported on PDSS2 




1 RR connection aborted 


release cause 


:= normal 




1 service not authorized 




1 Application not supported on PDSS2 




1 RR connection aborted (only in REL IND) 



NOTE 1: If the Appl-id specifies "unstructured", the service primitive may in addition specify a called party BCD 
number. 

NOTE 2: For further study: the indented volume of data might be negotiated for the purpose of optimized resource 
handling. 

NOTE 3: The possibility of data piggy backing is not considered in these tables. 

NOTE 4: For indication of the preferred or chosen channel. 

NOTE 5: Only in EST REQ and EST RSP 
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4.3 Interworking with supported applications 

When a PDSS1 or PDSS2 connection serves a certain application, an interworking function in the following sense is to 
be implemented at the service access points: 

If the application is different from "unstructured", data transferred between the access points in that connection 
are treated as protocol data units of the served application protocol respecting the rules of that protocol; in 
particular they are assumed to use addressing schemes of that application and are routed towards their 
destination in the resulting way. 

If the served application is "unstructured", explicit routing information may be contained as called party BCD 
number in the initial message at connection establishment; data transferred between the access points in that 
connection are assumed to be an unstructured bit sequence (this is again out of the scope of the present 
document). Packets are routed towards their destination based on the called party BCD number. Mobile to 
mobile data transport of the unstructured type is for further study. 

The detailed interworking with applications is out of the scope of the present document. 



5 General architecture 

For PDSS1, interworkings between MSC and supported applications have to be provided, see subclause 4.3; these are 
however out of scope of the present document. Between the MSC and MS the PDSS 1 protocol is run. On the A 
interface, DATA messages are transferred as DTAP messages. The MSC informs the BSS on which air interface 
signalling channel, the main or the associated one, DTAP messages are to be transferred. The other BSSAP procedures 
apply as usual. 

For PDSS2, a support node (PDSS2-SN) is introduced which communicates via the A p interface with the BSS. This 

node runs a simplified BSSAP protocol towards the BSS and the PDSS2 protocol towards the MS. It implements the 
necessary interworkings for the supported applications, see subclause 4.3. 

The functional split between BSC and BTS is the same as for signalling. 



6 Compatibility issues; interaction with other GSM 

services 

6.1 Use of PDS in parallel to basic services 

[NOTE: Interaction with other phase 2+ basic services has to be elaborated.] 

Parallel use of PDS and short message cell broadcast service (TS 23) is not required. There may, however, be Mobile 
Stations allowing parallel use, possibly depending on the channel used for the RR connection and SMSCB. 

For all other basic services (all requiring an CM connection), i.e. TS 1 1, 12, 21, 22, 61, 62, BS 21-26, BS 31-34, BS 41- 
46, BS 51-53, 81, the following applies: 

Mobile originating basic service: There is no restriction for a mobile originating CM connection establishment and 
following use of the basic service in parallel to a PDS connection. 

Mobile terminating basic service: During the establishment phase and release phase of an RR connection, there is a 
time when the mobile station is not pageable and where the MSC cannot transfer the information about the MT CM 
connection to be established to the MS. In most cases, the information can be transferred with delay. With the resulting 
exceptions, there is no restriction for a mobile terminating CM connection establishment and following use of the basic 
service in parallel to a PDSS1 connection. 
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While a Mobile Station is engaged in a PDSS2 service, the mobile subscriber may appear to the network as not 
reachable: 

a) When a mobile station uses PDSS2 and an MM connection exists, the MSC may initiate the CM connection 
establishment on the used RR connection. 

b) When a mobile station uses PDSS2 and no MM connection exists, there are three possible situations: 

1) The MS is establishing an RR connection. In this situation the MS doesn't listen to its paging subchannel. 

2) An RR connection is established, and the mobile station can listen to its paging subchannel without 
restriction to transmission on the RR connection (depending on the MS capabilities and the channel 
configuration). In this case the mobile station shall listen to the paging subchannel. 

3) An RR connection is established, and the mobile station can listen to its paging subchannel with restriction to 
transmission on the RR connection (depending on the MS capabilities and the channel configuration). In this 
case the mobile station may be configured to listen to the paging subchannel or not, possibly depending on 
the rate of missed signalling frames (including idle frames; in this case the channel is in signalling only 
mode). 

In any case, if the MS receives a paging, it shall send a PAGING RESPONSE message on the RR connection in 
use. The BSS shall use the PAGING RESPONSE as initial L3 message to the MSC. 

6.2 Interaction between PDS and supplementary services 

Supplementary services are not applicable to PDS; they may be applicable to an application using PDS. 

There is interaction between PDS and call offering supplementary services applied to other basic services: It is not 
predictable whether an MS engaged in a PDSS2 connection appear to the network as not reachable. In that case, CFNRc 
could become applicable. 



7 Transmission 

7.1 Common transmission aspects 

Both variants, PDSS1 and PDSS2, use acknowledged LAPDm transmission on SAPI on the air interface on the main 
signalling link or on the SACCH. 

NOTE: The usage of a new SAPI for PDSS1 and PDSS2 with optimized window size on FACCH is for further 

study. 

Each of them uses a new (different) L3 protocol discriminator. Messages are identified to belong to the same L3 PDSS1 
or PDSS2 connection by use of the transaction identifier. PDSS1 uses DTAP for transmission on the A interface, 
PDSS2 uses DTAP on the A„ interface. The transmission scheme on Abis uses the procedures for establishment and 

release of a link layer connection and transmission of a transparent message in acknowledged mode specified in TS 
GSM 08.58. 

Other interfaces are out of scope. 

7.1.1 Choice of the signalling link 

1) When the main link is an SDCCH or a TCH in signalling only mode, the main signalling link is to be used. 

2) Otherwise the channel is a TCH in a mode different from signalling only. 

a) If the network originates the transaction, the application in the MSC/PDSS2-SN decides whether to use 
FACCH or SACCH. 
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b) If the mobile originates the transaction, the application at the mobile station side decides whether to use the 
S ACCH or FACCH. The network may however reject the connection establishment (by sending a RELEASE 
COMPLETE message) with a specific cause indicating which link is to be used in situation 2) b). From then 
on the MS may only use the allowed links in situation 2) b) until it gets different information. 

This selection of the link is valid until there is a change of the channel to an SDCCH or a TCH in signalling only 
mode; then 1) applies and may require to change the link. 

7.1 .2 Priorities on the chosen signalling link 

PDS transmission by the MS on the SACCH shall be scheduled so that it is guarantied that measurement reports from 
the MS are transferred at least in every second block. PDS transmission by the BSS on the SACCH shall be scheduled 
so that it is guarantied that SYSTEM INFO messages are transferred at least in every nth block (n to be set by the 
implementation) . 

Other aspects for priority handling on the chosen signalling link are ffs. 

7.2 PDSS1 transmission aspects 
7.2.1 U m interface 

For PDSS1, a mobile originated MM connection is established with the procedures defined in GSM phase 2 (the CM 
SERVICE REQUEST indicates a new service type). A mobile terminated MM connection for PDSS1 is established 
implicitly (with the establishment of a PDSS1 connection). A PDSS1 connection is established by transmission of a 
SETUP message which 

identifies the PDP to be served; if this identification indicates "unstructured", the SETUP may also contain a 
called party BCD number; and which 

may contain a data part). 

The connection is confirmed by transmission of a SETUP ACKNOWLEDGE message (which may contain a data part). 
A connection is released and a connection establishment request is rejected by transmission of a RELEASE 
COMPLETE message (which specifies a cause and may contain a data part). Data is transferred in a DATA message. 

During a PDS SI connection, after a radio link failure the MS shall try to initiate CM re-establishment. If a cell 
supporting re-establishment has been found and the CM re-establishment has been accepted by MM, the MS shall try to 
resume the PDSS1 connection: 

When the MS receives a message with the transaction identifier of the PDSS1 connection, it shall 

if it is a PDSS 1 DATA message, implicitly resume that connection, 

if it is a PDSS 1 SETUP message, release that connection and treat the SETUP as the first message of a new 
transaction, 

- if it is a PDSS 1 RELEASE COMPLETE message, release that connection; 

if it did not yet perform such a release or implicit resumption, send a PDSS 1 RESUME REQUEST which may 
be 

- explicitly acknowledged by the network with a PDSS 1 RESUME ACK or 
implicitly accepted by the network with transmission of a DATA message or 
implicitly rejected by the network with the transmission of a PDSS1 SETUP or 

explicitly rejected by the network with the transmission of a PDSS1 RELEASE COMPLETE message 
(all these messages with the same transaction identification). 



ETSI 



3GPP TS 43.063 version 4.0.0 Release 4 1 3 ETSI TS 1 43 063 V4.0.0 (2001 -03) 

7.2.2 A interface 

PDSSl messages are transferred between MSC and BSS in DTAP messages. The A interface protocols are unchanged 
with the following two exceptions: 

as a general modification of the distribution sublayer, the Data Link Connection Identification (DLCI) parameter 
indicates the radio signalling link (main or associated) to be used for each DTAP message carrying a PDSSl 
message (for other applications, the DLCI may indicate that the BSS chooses the signalling link); 

- two new BSSAP messages are introduced, a SUSPEND message from BSS to MSC to inform the MSC that data 
transfer should be suspended, and a RESUME message from BSS to MSC to inform the MSC that data transfer 
can be resumed. 

7.3 PDSS2 transmission aspects 
7.3.1 U m interface 

For PDSS2, an MM connection is not used; an RR connection, however, is used. 

A PDSS2 connection is established by transmission of an IMMEDIATE SETUP message which 

contains the mobile station classmark 2 and a mobile identity, which 

indicates the PDP to be served; if this identification indicates "unstructured", the IMMEDIATE SETUP may also 
contain a called party BCD number; and which 

may contain a data part. 

The connection is confirmed by transmission of a SETUP ACKNOWLEDGE message (which may contain a data part). 
A PDSS2 connection is released and a connection establishment request is rejected by transmission of a RELEASE 
COMPLETE message (which specifies a cause and may contain a data part). Data is transferred in a DATA message. 

During a PDSS2 connection, 

(A) after a change of the radio channel (assignment or handover) and the corresponding L2 SAPI establishment or 
re-establishment (at return to the old channel) the MS shall regard the PDSS2 connection as suspended. It shall 
then try to resume the connection: 

When the MS receives a message with the transaction identifier of the PDSS2 connection, it shall 

if it is a PDSS2 DATA message, implicitly resume that connection, 

- if it is a PDSS2 RELEASE COMPLETE message, release that connection. 

- If the MS did not yet perform such a release or implicit resumption, it shall send a PDSS2 RESUME 
REQUEST which may be 

- explicitly acknowledged by the network with a PDSS2 RESUME ACK or 
implicitly accepted by the network with transmission of a DATA message or 

explicitly rejected by the network with the transmission of a PDSS2 RELEASE COMPLETE message 

(all these messages with the same transaction identification). 

(B) after a radio link failure the MS shall regard the PDSS2 connection as suspended. It shall then decide to abort the 
connection or to resume it. 
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In order to resume it, the RR sublayer is requested to establish an RR connection. There may be further requests 
for RR connection establishment, e.g. for CM re-establishment; these shall prevail. The further proceeding is as 
described below: 

- If the request from the PDSS2 sublayer is the only one, the MS shall send a PDSS2 RESUME REQUEST as first 
layer 3 message. 

Otherwise, after establishment of the RR connection, the MS continues as in (A). 

7.3.2 Ap interface 

On the A„ interface, layers 1 and 2 are implementation dependent (for example, layer 2 can be implemented by a higher 
layer underlaying protocol, e.g. X.25 or UDP/IP), but the following two requirements must be fulfilled: 

The BSS has to relate frames received from the PDSS2-SN to dedicated links on the air interface. 

The PDSS2-SN has to distinguish whether frames received on the A„ interface belong to the same or to different 
dedicated links of the air interface. 

This can be achieved by use of connection oriented L2 frame transfer on the A„ interface and by the BSS maintaining a 

one to one relation between RR connections of the air interface and layer 2 connections of the A„ interface (e.g. 

implemented by X.25 connections); it can, for example, also be achieved by implementing the L2 function by a session 
layered protocol and by maintaining a one to one relation between sessions of that protocol and RR connections. Note 
that at the same time an RR connection may be related to an SCCP connection on the A interface. This is not known to 
the PDSS2-SN and must be taken into account by the BSS. 

Between layer 2 and layer 3, the distribution sublayer defined in TS GSM 08.06 with the modifications described in 
subclause 7.2.2 is to be implemented. 

Layer 3 of the A„ interface consists in a part of the BSS AP protocol and the DTAP protocol as defined in TS GSM 

08.08 and two additional BSSAP messages, a SUSPEND message from BSS to MSC to inform the MSC that data 
transfer should be suspended, and a RESUME message from BSS to MSC to inform the MSC that data transfer can be 
resumed: The PDSS2 IMMEDIATE SETUP message is treated as initial MS message if it was received as the radio 
interface initial L3 message received from the MS, otherwise it is treated as a DTAP message; the messages CLEAR 
REQUEST, CLEAR COMMAND, CLEAR COMPLETE are used as defined in BSSMAP, all PDSS1 messages except 
the initial MS message are treated in the BSS as DTAP messages. The possibility of a parallel use of an RR connection 
by the MSC and the PDSS2-SN leads to the following consequence: 

When the BSS receives a CLEAR COMMAND or another indication that the RR connection is no more needed 
for PDSS2, it has to maintain the RR connection if it is still used for an A interface connection. 

- When the BSS receives a CLEAR COMMAND on the A interface or an indication that the A interface 
connection related to a certain RR connection is released, it has to maintain the RR connection if it is still used 
for an Ap interface connection. 

NOTE: The introduction of flow control messages on the A interface is ffs. 



8 Information storage 

8.1 Stored in the HLR 

Information concerning the subscription to PDSS1 shall be stored. 

8.2 Stored in the VLR 

Information concerning the subscription to PDSS1 shall be stored. 
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8.3 Stored in the MS 

The MS (ME/SIM) shall store whether PDSS1 and PDSS2 are supported in the location area. It shall also store which 
served PDP are not supported and - in case of PDSS2, which PDP addresses are not supported. 



9 Identities 

Identifiers for packet data protocols to be served must be specified. A special identifier indicates "unstructured"; in this 
case, a called party BCD number as specified in TS GSM 04.08 may be used to identify the destination of packets. 

Mobile identity: For certain applications, a new mobile identity type "anonymous" has to be specified which may 
contain an operator specific group id and otherwise consists in a random number. A mobile station which applies 
the anonymous mobile identity for establishment of a PDSS 1 or PDSS2 connection shall use for that 
establishment the access class A-AC(i) determined from its IMEI i by application of an algorithm A- AC defined 
below. 

Algorithm A-AC: This algorithm is manufacturer dependent; it is the same for all mobile stations with equal type 
approval code and final assembly code. A-AC computes an access class A-AC(i) between and 9 from an IMEI 
i. The choice of A-AC and the assignment of serial numbers to mobile equipment shall guarantee that for each 
access class x between and 9, among the mobile stations with equal type approval code and final assembly 
code, more than 8% and less than 12% have access class x determined from their IMEI by application of A-AC. 
This requirement applies if there are more than 49 mobile stations with equal type approval code and final 
assembly code. 



10 Operation and maintenance aspects 

NOTE: A list and short description of the operation and maintenance aspects will be given. This includes the 
options and parameters which can be set by the operator. 



1 1 Functions and information flow 
11.1 Subscription 

When the subscriber record is created in the HLR, subscriptions to PDSS1 shall be included. 



1 1 .2 Change of subscription 



The network operator can change subscription for PDSS1 at any time. The subscriber cannot change the subscription 
via the MMI. 
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11.3 Overview of signalling 



In this overview, the message structure to implement the specified concept are identified, and brief details are given of 
each message. 



MS 



BSS 



MSC 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(MM:CM SERVICE REQ) 

UA (L3 message) 

PDSS1:SETUP 

PDSS1:SETUPACK 

PDSS1 :DATA 

PDSS1 :DATA 

PDSS1 :DATA 



PDSS1 :RELEASE COMPLETE 



COMPLETE L3 INFO 
DTAP(SETUP) 

DTAP(SETUP ACK) 
DTAP(DATA) 
DTAP(DATA) 
DTAP(DATA) 



DTAP(RELEASE COMPLETE) 
CLEAR COMMAND 



CHANNEL RELEASE 



CLEAR COMPLETE 



Figure 1 : Signalling flow for mobile originating PDSS1 (starting in idle mode, release by MSC) 

NOTE: The radio channel release is only initiated if no PDSS2 connection for the RR connection exists. This note 
applies also to the other message sequence diagrams of PDSS1 in this section. 

CHANNEL REQUEST: Standard message. 

IMMEDIATE ASSIGNMENT: Standard message. 

CM SERVICE REQUEST: Standard message, specifying new CM service type "PDSS1", transported in a LAPDm 
SABM frame as defined in TS GSM 04.06 and 04.08. 

UA (layer 3 message): LAPDm UA frame repeating the L3 message received in the SABM, as defined in TS GSM 
04.06 and 04.08. 

COMPLETE L3 INFO: BSSMAP message containing the initial MS message. 

SETUP: Message of the PDSS1 protocol. It identifies the PDP to be used. If this identification specifies "unstructured", 
it may contain a called party BCD number as specified in TS GSM 04.08. 

SETUP ACKNOWLEDGE: PDSS1 message telling the MS that the PDSS1 connection is established. It may contain 
a data part. 

DATA: PDSS1 message (defined in both directions) containing PDP data. 

CLEAR COMMAND, CLEAR COMPLETE, CHANNEL RELEASE: Standard messages. 
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MS 



BSS 



MSC 



BSSMAPPAGING 



RRPAGING REQUEST 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(RR:PAGING RESPONSE) 

UA (L3 message) 

PDSS1:SETUP 

PDSS1:SETUPACK 

PDSS1 :DATA 

PDSS1 :DATA 

PDSS1 :DATA 



PDSS1 :RELEASE COMPLETE 



CHANNEL RELEASE 



COMPLETE L3 INFO 
DTAP(SETUP) 

DTAP(SETUP ACK) 
DTAP(DATA) 
DTAP(DATA) 
DTAP(DATA) 



DTAP(RELEASE COMPLETE) 



CLEAR COMMAND 
CLEAR COMPLETE 



Figure 2: Signalling flow for mobile terminating PDSS1 (from idle mode, release by mobile station) 

MS BSS MSC 



PDSS1 :DATA 
PDSS1 :DATA 
PDSS1 :DATA 



DTAP(DATA 
DTAP(DATA 
DTAP(DATA 



<radio link failure or 
abortion in the BSS> 



CLEAR REQUEST* 



CLEAR COMMAND 



CLEAR COMPLETE 



*)Note: With appropriate cause. Alternatively to the BSS originated clearing procedure a release of the 
underlaying connection might be used. 

Figure 3: Signalling flow for PDSS1 (from PDSS1 -connected mode: radio link failure or radio link 

abortion in the BSS) 
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MS 



BSS 



MSC 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(MM:CM SERICE REQ) 

UA (L3 message) 

MM:ABORT or CM SERVICE REJ 



CHANNEL RELEASE 



COMPLETE L3 INFO 



DTAP(ABORT or CM SERV REJ) 
CLEAR COMMAND 
CLEAR COMPLETE 



Figure 4: Signalling flow for PDSS1 (rejection of PDSS1 -service) 

MS BSS MSC 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(MM:CM SERICE REQ) 

UA (L3 message) 

PDSS1:SETUP 
PDSS1 :RELEASE COMPLETE 



CHANNEL RELEASE 



COMPLETE L3 INFO 



DTAP(SETUP) 

DTAP(RELEASE COMPLETE) 

CLEAR COMMAND 

CLEAR COMPLETE 



Figure 5: Signalling flow for PDSS1 (rejection of service after setup) 



ETSI 



3GPP TS 43.063 version 4.0.0 Release 4 



19 



ETSI TS 143 063 V4.0.0 (2001-03) 



MS 



BSS 



PDSS2-SN 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(PDSS2: IMM SETUP) 

UA (L3 message) 

PDSS2:SETUP ACK 

PDSS2:DATA 

PDSS2:DATA 

PDSS2:DATA 



COMPLETE L3 INFO 

DTAP(SETUP ACK) 

DTAP(DATA) 

DTAP(DATA) 

DTAP(DATA) 



PDSS2:RELEASE COMPLETE 



CHANNEL RELEASE 



DTAP(RELEASE COMPLETE) 
CLEAR COMMAND 



CLEAR COMPLETE 



Figure 6: Signalling flow for PDSS2 (release by support node) 

CHANNEL REQUEST: Standard message. 

IMMEDIATE ASSIGNMENT: Standard message. 

IMMEDIATE SETUP: Message of the PDSS2 protocol, transferred in a LAPDm SABM frame. The IMMEDIATE 
SETUP message is limited to the length of the LAPDm SABM frame data part (20 bytes). It is similar to the MM 
message CM SERVICE REQUEST (octet 3 is spare, and is followed by mobile station classmark and mobile identity). 
It identifies the PDP to be used. If this identification specifies "unstructured", it may contain a called party BCD number 
as specified in TS GSM 04.08. (If the PDP requires itself a first message which is to long to be contained in the data 
part of the SETUP, the data part of the IMMEDIATE SETUP must remain empty, and the PDP message has to be 
transferred in a DATA message). 

UA (layer 3 message): LAPDm UA frame repeating the L3 message received in the SABM, as defined in TS GSM 
04.06 and 04.08. 

COMPLETE L3 INFO: BSSMAP message containing the initial MS message. If a connection oriented frame transfer 
is used on the A p interface, a connection must be established prior to or together with transmission of the COMPLETE 

L3 INFO. 

SETUP ACKNOWLEDGE: PDSS2 message telling the MS that the PDSS2 connection is established. It may contain 
a data part. 

DATA: PDSS2 message (defined in both directions) containing PDP data. 

CLEAR COMMAND, CLEAR COMPLETE, CHANNEL RELEASE: Standard messages. 
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MS 



BSS 



PDSS2-SN 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(PDSS2:IMM SETUP) 

UA (L3 message) 

PDSS2:SETUP ACK 

PDSS2:DATA 

PDSS2:DATA 

PDSS2:DATA 



PDSS2:RELEASE COMPLETE 



CHANNEL RELEASE 



COMPLETE L3 INFO 

DTAP(SETUP ACK) 

DTAP(DATA) 

DTAP(DATA) 

DTAP(DATA) 



DTAP(RELEASE COMPLETE) 



CLEAR COMMAND 
CLEAR COMPLETE 



Figure 7: Signalling flow for PDSS2 (release by mobile station) 

NOTE: The radio channel release is only initiated if no A interface connection for the RR connection exists. This 
note applies also to the other message sequence diagrams of PDSS2 in this section. 
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MS 



BSS 



PDSS2-SN 



RR:CHANNEL REQUEST 

RR: IMMEDIATE ASS 

L2:SABM(PDSS2:IMM SETUP) 

UA (L3 message) 

PDSS2:SETUP ACK 

PDSS2:DATA 

PDSS2:DATA 

PDSS2:DATA 



COMPLETE L3 INFO 

DTAP(SETUP ACK) 

DTAP(DATA) 

DTAP(DATA) 

DTAP(DATA) 



<radio link failure or 

abortion in the BSS 

or handover> 



CLEAR REQUEST* 



CLEAR COMMAND 



CLEAR COMPLETE 



*) NOTE: With appropriate cause. If a connection oriented protocol is underlaying BSSAP, alternatively to the BSS 
originated clearing procedure a release of the underlaying connection may be used. 

Figure 8: Signalling flow for PDSS2 (radio link failure or abortion in the BSS or handover) 

MS BSS PDSS2-SN 

RR:CHANNEL REQUEST 
> 

RR: IMMEDIATE ASS 
< 

L2:SABM(PDSS2:IMM SETUP) 
> 

UA (L3 message) COMPLETE L3 INFO 
< > 

PDSS2:RELEASE COMPLETE DTAP(RELEASE COMPLETE) 
< 

CLEAR COMMAND 
< 

CHANNEL RELEASE CLEAR COMPLETE 



Figure 9: Signalling flow for PDSS2 (rejection of service) 
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